As the value and use of information continues to increase, individuals and businesses seek additional ways to process and store information. One option available to users is information handling systems (e.g. databases). An information handling system generally processes, compiles, stores, and/or communicates information or data for business, personal, or other purposes thereby allowing users to take advantage of the value of the information. Because technology and information handling needs and requirements vary between different users or applications, information handling systems may also vary regarding what information is handled, how the information is handled, how much information is processed, stored, or communicated, and how quickly and efficiently the information may be processed, stored, or communicated. The variations in information handling systems allow for information handling systems to be general or configured for a specific user or specific use such as financial transaction processing, airline reservations, enterprise data storage, or global communications. In addition, information handling systems may include a variety of hardware and software components that may be configured to process, store, and communicate information and may include one or more computer systems, data storage systems, and networking systems.
Databases, such as relational database management systems (RDBMS), may use indexes of tables when executing database queries, such as queries in Structured Query Language (SQL). An index of a table is a lookup table that a database search engine can use to speed up data retrieval, similar to how an index of a book can speed up finding where a particular topic is discussed in the book. For example, the index may be a pointer to data in the table. As SQL operations (e.g., INSERT, UPDATE, DELETE, or the like) are performed to the table, over a period of time, the index may become fragmented. For example, the index fragmentation may cause the index to increase in physical size and become less densely populated. A fragmented index may cause the database to execute SQL queries less efficiently, as each physical I/O operation yields a reduced volume of information from the index file during each read/write operation. Thus, as index fragmentation increases, the efficiency with which SQL queries are executed may decrease.
The typical resolution to the problem of index fragmentation is for a database administrator (DBA) to periodically check on indexes to identify indexes that are significantly fragmented, and either (a) defragment them while the index is in-service (e.g., while the index remains available to the SQL execution engine), or (b) take the index offline (e.g., during an off-peak time) and rebuild the index. During the index rebuild, the SQL execution engine may revert to non-index-based operations in order to perform a query. For example, an inefficient operation, such as a full-table-scan, may be used during the period of time that an index is being rebuilt. Option (a) is preferential to option (b) because option (a) provides more efficient database access. Thus, a DBA may prefer to identify fragmentation early (i.e. before it gets too bad) to enable the DBA to select option (a). If the fragmentation is significant (e.g., greater than a predetermined threshold), then option (a) may be unavailable and the DBA may select option (b). However, having a DBA manually check the fragmentation of indexes manually to identify fragmented indexes may be time consuming and tedious.